ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/tsql/doc/tsql.mail/[e-mail]…s64.cineca.it _Thu May 13 18:26:14 1993.msg

Internet Message Format | 1996-01-31 | 4KB

Received: from icineca.cineca.it by optima.CS.Arizona.EDU (5.65c/15) via SMTP
    id AA19002; Thu, 13 May 1993 09:24:18 MST
Received: from deis64.cineca.it by ICINECA.CINECA.IT (IBM VM SMTP V2R2)
   with TCP; Thu, 13 May 93 18:24:40 SET
Received: from [137.204.57.79] (deis79) by deis64.cineca.it (4.1/SMI-4.1)
    id AA24546; Thu, 13 May 93 18:26:30 +0200
Date: Thu, 13 May 93 18:26:14 +0100
From: (Fabio Grandi) <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Benchmark Query Taxonomy

Dear Christian,
I greatly appreciate your prompt answer to my doubts.

Here are some adds to my previous message.
I hope they can make my previous problems clearer.

I'm sorry I used for the Output-based Taxonomy a syntax improperly
derived from Fig. 2, without checking its correctness
wrt definitions in Figures 6 and 7.

1) My classification examples (a) and (b) only refer to
   the first part of the taxonomy (i.e. output).

2) With reference to Fig. 2, my classification examples were:

 (a) - (Projected, None)
     which fits the template: { Projected } x { None }
     and whose correct syntax is: ( Projected, None )

 (b) - (None, (*, "value") )
     which fits the template: { None x { { * } x { "value" } }
     and whose correct syntax is: ( None, *, "value" )
     according to the <output> production rule of Fig. 6.

     I used '*' for the "type" field to denote 'any' temporal type
     (i.e. event, interval, or element), whereas I left the name "value"
     to denote a definite value type (i.e. derived or imposed),
     whose choice was the subject of the discussion which followed
     the classification examples.

The correct syntax of (b) according to the <reduced output> rule
    of Fig. 7 is: ( None, Not empty ).


I agree with the classification (Projected, None) of the output
of the query "Find the date of birth of *ED*", as you can see from
my last comments of my first message.

My only problem is that the so retrieved "user-defined time",
is an "explicit-attribute" value that has a meaning of valid-time
even more marked - in my opinion - than the value retrieved by a query
with output (None, *, Imposed) in the taxonomy of Fig. 6.
For this reason I suggested to eliminate the case 'Imposed' from
the "value" component in Fig. 2.

On the other hand, an alternative solution which I tried to suggest
in my previous discussion could be better stated as follows:

We could allow an 'Imposed' value of the valid-time component
of the output to be computed:
 - either by explicit assignment in the query,
 - or from user-defined time attributes
   (of the tuples in the argument relation).

The latter case was not provided for in your taxonomy.
In both cases, we deal with some value which had no valid-time
meaning in the argument data but which we want to have an (imposed)
valid-time meaning in the output produced.

Do you agree with this?


A quite irrelevant - but somehow related - problem
outlined in my first message can be better formulated as:

Is it crucial for the taxonomy the distinction between
"user-defined attribute value" and "computed from other valid times"
in Fig. 4 (User-defined vs Computed in Fig. 8) ?


Finally, I would like to let you notice that - when transaction-time
will be included in a future version of the taxonomy -
my discussion about using user-defined time where valid-time is required
applies as well to using transaction-time where valid-time is required
(and vice versa). For instance, also transaction-time computed from data
could be used as an imposed value of the valid-time component of
the query output.

Sincerely,
     Fabio Grandi.